REMARKS 



Claims 13 and 22 are canceled and claims 1,15 and 24 are amended. Claims 
1-12, 14-21 and 23-26 are pending in the application. As required by 37 CFR § 1.121, 
Applicant submits a version with markings showing changes to the application. In light 
of the amendments and following remarks, Applicant believes all the pending claims are 
now in condition for allowance. 

Formal Matters 

Applicant appreciates the Examiner's careful review of the application and has 
amended the specification to correct the typographical errors cited in the Office Action. 
Accordingly, the objection to the disclosure is overcome. 

Claims 1-26 were rejected under 35 USC § 1 12, second paragraph, as allegedly 
not particularly pointing out and claiming the invention. More specifically, the Office 
Action alleged that it is unclear whether "general-purpose blocks" are for software 
configuration, hardware configuration, or both. In general, the general-purpose blocks 
are for software configuration of the system. However, as with all changes to software, 
software directs how the underlying hardware operates so any change in software will 
be manifested in some manner in hardware. Typically, changes in software affect the 
code that is stored and the operation of the hardware when it runs that code. Applicant 
believes that one of ordinary skill in the art would understand these concepts and 
requests that the rejection be withdrawn. 

The § 1020)) Rejection of Claims 1-23 

Claims 1-23 were rejected under 35 USC § 102(b) as allegedly being anticipated 
by U.S. Patent No. 5,488,650, issued January 30, 1996 to Greco et al. (hereinafter 
"Greco"). In a sincere effort to expedite prosecution, Applicant amended the 
independent claims to include the transfer blocks (e.g., features from claim 13). 
Applicant reserves all right to pursue the original or other claims in a continuing 
application. For the following reasons, Greco does not support a prima facie case of 
anticipation. 




Greco does not disclose transfer blocks, coupled to general-purpose blocks, that 
are configurable to transfer a call to a specified telephone number. For example, claim 
1 recites as follows: 

a plurality of transfer blocks, each transfer block being coupled to 
a general-purpose block to receive one of the first or second signals and is 
configurable to transfer a call to a specified telephone number. 

Thus, the transfer blocks receive a signal from a general-purpose block and can be 
configured to transfer a call to a specified telephone number. 

Applicant appreciates the Examiner's time in creating an example in the Office 
Action. However, the example alleges that the menu sets in Greco are "general-purpose 
blocks" as claimed. Assuming for the sake of argument this was true, the Office Action 
then argues that the "general -purpose blocks" in Greco are the claimed transfer blocks 
(citing col. 4, lines 6-8). The Office Action never cites transfer blocks in Greco, but 
instead alleges that the "general-purpose blocks" in Greco are transfer blocks. A closer 
inspection of Greco reveals this is not the case. 

The Office Action alleges that a "general-transfer block" of Greco can transfer a 
call to an extension or change the extension number by using action code 105 (citing 
col. 7, Table 1). As recited in Table 1, action 105 is for " Toggle extension transfer and 
change number" (emphasis supplied). Toggling means that action 105 turns a feature on 
or off, but it does not teach a transfer block that is configurable to transfer a call to a 
specified telephone number as claimed. Accordingly, Greco does not disclose all the 
features of claim 1. 

As Greco does not support a prima facie case of anticipation, claims 1-12, 14-21 
and 23 are patentably distinct and should be passed to issue. Additionally, claims 15-21 
and 23 include further features of selecting a transfer block and specifying a telephone 
number for the selected transfer block. These claims are further patentably distinct as it 
has not been shown that Greco describes these features. 

The § 102(b) Rejection of Claims 24-26 

Claims 24-26 were rejected under 35 USC § 102(b) as allegedly being 
anticipated by U.S. Patent No. 4,602,129, issued July 22, 1986 to Matthews et al. 
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(hereinafter "Matthews"). For the following reasons, Matthews does not support a 
prima facie case of anticipation. 

Claim 24 has been amended to recite as follows: 

executing the interactive voice response system, the system 
including a plurality of general-purpose blocks and a plurality of transfer 
blocks that are configurable to transfer a call to a specified telephone 
number; 

The Office Action does not show where Matthews discloses the recited features of 
transfer blocks as claimed. Additionally, the above shows that it has not been shown 
that Greco discloses these features either. Accordingly, the cited art does not support a 
prima facie case of anticipation and claims 24-26 should be passed to issue. 



For the foregoing reasons, Applicant believes all the pending claims are in 
condition for allowance and should be passed to issue. If any fees are due in connection 
with the filing of this amendment, the Commissioner is authorized to charge such fees 
to Deposit Account 19-2179. 



Conclusion 



Respectfully submitted, 




Rosa S. Kim 



Reg. No. 39,728 



Siemens Corporation 
Intellectual Property Department 
1 86 Wood Avenue South 
Iselin, NJ 08830 
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VERSION WITH MARKINGS TO SHOW CHANGES 
MADE TO THE APPLICATION 



In the Specification 

The paragraph beginning on page 2, line 23 was amended as follows: 
Although application generators make creating and maintaining IVR systems 
easier, they still can be difficult to master. For example, there are possibly over 50 
graphical icons shown in FIG. 1, with each icon being designed for a specific purpose. 
Although the graphical image of the icons may aid the user's understanding of the 
function that is provided, it still may be difficult to fully master the power and 
capabilities provided. Additionally, once the application is configured, the application 
generator generates an executable software module that needs to be executed in order to 
have the application run and perform the functions the user has configured. If there is a 
change in the configuration, the application generator needs to generate the executable 
software module that executes the newly modified version of the application before the 
configuration change takes [take] effect. However, in systems that require non-stop 
operation, it is not practical to terminate an old version of the application so that the 
newly modified version can be started. This can make it difficult to modify a running 
IVR system because the running software application may need to be brought down, in 
order to install the updated version. 

The paragraph beginning on page 6, line 15 was amended as follows: 
A box 204 indicates that a signal InitEnd can be sent after prompt 203 is played. 
The InitEnd will be sent if box 204 is configured as empty meaning that this path is 
configured as valid. As shown in this example, box 204 is closed, indicating that the 
valid path would proceed through a box 206 which is empty. In a preferred 
embodiment, boxes 204 and 206 are mutually exclusive such that the general-purpose 
block can be configured to play a prompt and then send a signal or play a prompt and 
process received input (and subsequently send a signal). When boxes 204 and 206 [26] 
are configured to play the prompt and process received input, prompt 203 is typically a 
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voice message. In other embodiments such as in ToL systems, a video message or an 
audiovisual message can be played for prompt 203. 

In the Claims 

Claims 13 and 22 were canceled without prejudice and claims 1,15 and 24 were 
amended as follows: 

1 . (Amended) An interactive voice response system, comprising: 

a plurality of general-purpose blocks, each general-purpose block being coupled 
to at least one other general-purpose block, wherein each general-purpose block plays a 
prompt and is configurable to send a first signal after playing the prompt or send a 
second signal according to received input after playing the prompt ; and 

a plurality of transfer blocks, each transfer block being coupled to a general- 
purpose block to receive one of the first or second signals and is configurable to transfer 
a call to a specified telephone number . 

15. (Amended) A method of generating an interactive voice response 
application, comprising: 

providing a plurality of general-purpose blocks, each general-purpose block 
being preconfigured to send signals to at least one other general-purpose block; 

selecting a general-purpose block; 



specifying a prompt that the selected general-purpose block will play; [and] 

specifying whether the selected general-purpose block will send a first signal 
after playing the prompt or send a second signal according to received input after 
playing the prompt; 

providing a plurality of transfer blocks, each transfer block being coupled to a 
general-purpose block to receive one of the first or second signals to transfer a call to a 
telephone number; 

selecting a transfer block; and 

specifying the telephone number for the selected transfer block . 

24. (Amended) A method of modifying an interactive voice response system 
at run-time, comprising: 

executing the interactive voice response system, the system including a plurality 
of general-purpose blocks and a plurality of transfer blocks that are configurable to 
transfer a call to a specified telephone number ; 

modifying a configuration of a selected general-purpose block; and 

updating the configuration of the selected general-purpose block at run-time. 
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